Systems, methods and computer program products for providing disease and/or condition specific adaptive mobile health content, applications and/or solutions

ABSTRACT

Systems, methods and computer program products for providing condition specific adaptive content include receiving condition specific information into a data repository, defining requirements corresponding to the condition specific information, building a condition specific application based on the requirements, configuring the condition specific application corresponding to user-specific attribute and delivering the condition specific application to a processing device that is operable to execute the condition specific application.

CROSS-REFERENCE TO RELATED APPLICATION

This U.S. non-provisional patent application is a divisional of U.S.patent application Ser. No. 13/838,698, filed Mar. 15, 2013 which itselfclaims priority to provisional patent application No. 61/663,034 filedon Jun. 22, 2012 in the U.S.P.T.O, the contents of which in its entiretyare herein incorporated by reference.

FIELD OF THE INVENTION

The present invention relates generally to communication and, moreparticularly, to systems, methods and computer program products fordelivery of applications.

BACKGROUND

Many industries may utilize and/or rely on communications with multipleclasses of users. For example, the healthcare and pharmaceuticalindustries may rely on communications between various classes includinghealthcare providers, such as doctors and/or nurses, patients,prospective patients, and/or clients, such as, for example, healthcareresearch organizations, medical device manufacturers and/orpharmaceutical companies, among others. Advances in technology haveprovided for wireless communication systems using, for example, mobileterminals. However, functionality of mobile terminals may vary as afunction of hardware, software, and/or services, among others.Accordingly, currently available systems and methods may not be suitablefor providing ubiquitous mobile applications through the various mobileterminals.

SUMMARY

Some embodiments of the present invention are directed to methods ofproviding condition specific adaptive content. Such methods may includereceiving condition specific information into a data repository,defining condition specific application requirements corresponding tothe condition specific information, building a condition specificapplication based on the requirements, configuring the conditionspecific application corresponding to user-specific attributes anddelivering the condition specific application to a processing devicethat is operable to execute the condition specific application.

Some embodiments provide that the processing device includes a mobileterminal. In some embodiments, receiving the condition specificinformation includes receiving health condition related data. Someembodiments provide that receiving the condition specific informationincludes receiving disease specific data. Some embodiments provide thatdefining requirements corresponding to the condition specificinformation includes selecting a disease, selecting at least one diseaseattribute of multiple disease attributes, and selecting at least onedisease functional component of the condition specific applicationcorresponding to the selected at least one disease attribute.

In some embodiments, building the condition specific applicationincludes defining function metadata corresponding to at least onefunctional component of the condition specific application, defining atleast one function element based on the function metadata and defining afunction interface that corresponds to the at least one functionalcomponent of the condition specific application.

Some embodiments provide that configuring the condition specificapplication corresponding to user-specific attributes includes defininggeneral rules and/or workflow corresponding to the condition specificapplication, configuring multiple condition stages that are specific tothe condition, mapping multiple behavior stages of the user thatcorrespond to ones of the condition stages, mapping knowledgebasecontent to the condition stages and/or the behavior stages.

In some embodiments, delivering the condition specific application tothe processing device that is operable to execute the condition specificapplication includes assessing multiple capabilities corresponding tothe processing device, the user and/or at least one peripheral deviceattached thereto, packaging the condition specific applicationcorresponding to the capabilities of the processing device, the userand/or at least one peripheral device and modifying the packagedcondition specific application to include user specific data.

Some embodiments further include modifying at least one component and/oroperating mode of the condition specific application responsive to achange in the condition and/or user behavior.

Some embodiments of the present invention include computer programproducts for providing condition specific adaptive content. The computerprogram products may include a non-transitory computer-readable mediumhaving executable computer-readable program code therein, thecomputer-readable program code being configured to implement operationsand/or methods disclosed herein.

Some embodiments are directed to computer program products that includea non-transitory computer readable storage medium having computerreadable program code embodied therein. The computer readable programcode may include computer readable program code that is configured todefine requirements corresponding to disease specific information,computer readable program code that is configured to generate a diseasespecific application for execution on a mobile terminal, the diseasespecific application including functional elements corresponding to thedisease and that is configured according to a stage of the disease and acorresponding patient behavioral stage, and computer readable programcode that is configured to deliver the disease specific application tothe mobile terminal based on properties corresponding to the mobileterminal.

Some embodiments are directed to computer systems. Such systems mayinclude at least one processor and at least one memory coupled to the atleast one processor, the memory including computer readable program codeembodied therein that, when executed by the processor, causes theprocessor to perform operations as described herein.

It is noted that aspects of the inventive concept described with respectto one embodiment, may be incorporated in a different embodimentalthough not specifically described relative thereto. That is, allembodiments and/or features of any embodiment can be combined in any wayand/or combination. These and other objects and/or aspects of thepresent inventive concept are explained in detail in the specificationset forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying figures are included to provide a further understandingof the present inventive concept, and are incorporated in and constitutea part of this specification. The drawings illustrate some embodimentsof the present inventive concept and, together with the description,serve to explain principles of the present inventive concept.

FIG. 1 is a block diagram illustrating operations for providingcondition specific adaptive content according to some embodiments of thepresent invention.

FIG. 2 is a block diagram that illustrates operations and workflowcorresponding to systems and methods according to some embodiments ofthe present invention.

FIG. 3 is a flow diagram illustrating an overview of stages forproviding an adaptive mHealth solution according to some embodiments ofthe present invention.

FIG. 4 is a flow diagram illustrating the stages described aboveregarding FIG. 3 including operations and flow therein according to someembodiments of the present invention.

FIG. 5 is a block diagram illustrating operations and workflowscorresponding to systems and methods as disclosed herein integratedwithin a healthcare ecosystem in accordance with some embodiments of thepresent invention.

FIG. 6 is an illustration of the different functions and components in aCF specific mHealth product according to the example described above.

FIG. 7 is an illustration of different functions and components in anAttention Deficit-Hyperactivity Disorder (ADHD) specific productaccording to some embodiments of the present invention.

FIG. 8 is an illustration of different functions and components in aChronic Obstructive Pulmonary Disease (COPD) specific product accordingto some embodiments of the present invention.

FIG. 9 is a block diagram illustrating systems/methods/operations forproviding condition specific adaptive content according to someembodiments of the present invention.

FIG. 10 is a block diagram illustrating systems/methods/operations forproviding condition specific adaptive content according to someembodiments of the present invention.

FIG. 11 is a block diagram illustrating different access portal layoutscreen configurations corresponding to different classes of electronicdevices through which a patient may access systems provided according tosome embodiments disclosed herein.

FIG. 12 is a flow diagram illustrating a high level architecturecorresponding to systems, methods, solutions and computer programproducts according to some embodiments of the present invention.

DETAILED DESCRIPTION

The present invention now will be described more fully hereinafter withreference to the accompanying drawings, in which embodiments of theinvention are shown. However, this invention should not be construed aslimited to the embodiments set forth herein. Rather, these embodimentsare provided so that this disclosure will be thorough and complete, andwill fully convey the scope of the invention to those skilled in theart.

It will be understood that, although the terms first, second, etc. maybe used herein to describe various elements, these elements should notbe limited by these terms. These terms are only used to distinguish oneelement from another element. Thus, a first element discussed belowcould be termed a second element without departing from the scope of thepresent invention. In addition, as used herein, the singular forms “a”,“an” and “the” are intended to include the plural forms as well, unlessthe context clearly indicates otherwise. It also will be understoodthat, as used herein, the term “comprising” or “comprises” isopen-ended, and includes one or more stated elements, steps and/orfunctions without precluding one or more unstated elements, steps and/orfunctions. The term “and/or” includes any and all combinations of one ormore of the associated listed items.

It will also be understood that when an element is referred to as being“connected” to another element, it can be directly connected to theother element or intervening elements may be present. In contrast, whenan element is referred to as being “directly connected” to anotherelement, there are no intervening elements present. It will also beunderstood that the sizes and relative orientations of the illustratedelements are not shown to scale, and in some instances they have beenexaggerated for purposes of explanation.

Unless otherwise defined, all terms (including technical and scientificterms) used herein have the same meaning as commonly understood by oneof ordinary skill in the art to which this invention belongs. It will befurther understood that terms, such as those defined in commonly useddictionaries, should be interpreted as having a meaning that isconsistent with their meaning in the context of the relevant art andthis specification and will not be interpreted in an idealized or overlyformal sense unless expressly so defined herein. The present inventionwill now be described more fully hereinafter with reference to theaccompanying drawings, in which some embodiments of the invention areshown. This invention, however, may be embodied in many different formsand should not be construed as limited to the embodiments set forthherein. Rather, these embodiments are provided so that this disclosurewill be thorough and complete, and will fully convey the scope of theinvention to those skilled in the art.

It should be construed that forgoing general illustrations and followingdetailed descriptions are exemplified and an additional explanation ofclaimed inventions is provided.

Reference numerals are indicated in detail in some embodiments of thepresent invention, and their examples are represented in referencedrawings. Throughout the drawings, like reference numerals are used forreferring to the same or similar elements in the description anddrawings.

Pursuant to embodiments of the present invention, systems and methodsare provided for providing compliant messaging services. Compliance maybe required for applications used in, for example, healthcare and/orpharmaceutical industries. In some embodiments, a sponsor, such as apharmaceutical provider, for example, may initiate and/or manage acampaign such as, for example, a clinical and/or marketing studyregarding a new drug and/or drug application and/or disease condition.In some embodiments, a campaign may include a prescription reminderservice, health surveys and/or questionnaires, and/or services forincreasing the patient's compliance with a clinical study or drugregimen. In this regard, a campaign may include a series of eventsand/or operations undertaken to achieve a specific goal. As describedherein, campaigns may be directed to gathering and/or disseminatinginformation and/or data corresponding to a clinical and/or marketingstudy regarding a new drug and/or drug application, disease conditionand/or a prescription reminder service, among others. Concomitant withsuch studies may be strict requirements including audit trails,validation, authentication and/or confidentiality, among others.Additionally, as a practical matter, global connectivity, sufficientencryption and performance, multi-lingual capability and/or integrationflexibility may be necessary as well. In this regard, a trusted thirdparty to manage the management, data, communications, and/or complianceissues associated with such campaigns may be beneficial. For example, insome regulatory environments, sponsors may be prohibited from havingdirect contact with and/or storing any customer, subject and/or patientdata, among others.

Some embodiments as described herein may be used in conjunction withand/or may benefit from information disclosed in pending patentapplication Ser. No. 12/434,244 filed May 1, 2009, entitled “Systems,Methods and Computer Program Products For Providing Compliant MessagingServices”, the contents of which are incorporated by reference as ifentirely set forth herein. Some embodiments described herein may be usedin conjunction with and/or benefit from information disclosed in pendingpatent application Ser. No. 13/459,573 filed Apr. 30, 2012, entitled“Systems, Methods and Computer Program Products For Providing CompliantDelivery of Content, Applications and/or Solutions”, the contents ofwhich are incorporated by reference as if entirely set forth herein

In some embodiments of the present invention, disease/condition specificmobile health solutions may be designed, built, delivered andmaintained. Such solutions may provide dynamic support and managementfor a patient and be adaptive to support individual patient/consumerneeds and/or preferences. Although some embodiments are directed toproviding solutions to patients, some embodiments include solutions thatare directed to using patient data to provide dynamic support andmanagement for health care professionals, clients, payers and/orcaregivers, among others. Although discussed herein in the context ofhealthcare such that target consumers may be patients, this disclosureis not so limited. For example, the methods, systems, operations and/orprocesses may be applied to other industries including agriculture,horticulture, animal management, industrial monitoring, executive and/orworkforce performance management and/or monitoring, sporting and/orathletic performance management and/or monitoring, industrial processes,transportation, and/or network services, among others.

Embodiments disclosed herein may provide systems, methods and computerprogram products for providing personal care for a patient and/or user.For example, as described herein, patient treatment may be personalizedby compliantly using personalized technology. In this manner,embodiments disclosed herein may dynamically launch mobile content,solutions and/or applications that are catered to user and/or patientspecific needs, which may be identified in terms of individual and/ortechnological capabilities.

Reference is now made to FIG. 1, which is a block diagram illustratingoperations for providing condition specific adaptive content accordingto some embodiments of the present invention. Operations includereceiving condition specific information into a data repository (block100). Some embodiments provide that the condition specific informationincludes health condition related data. For example, the conditionspecific information may include disease specific data. Sources forcondition specific information may include one or more datarepositories, services and/or publications regarding conditions and/ordiseases, and disease findings.

Condition specific application requirements corresponding to thecondition specific information may be defined (block 102). In someembodiments, the requirements may be defined, in part, via a mobilehealth request or identification provided by a health professional, suchas a doctor, nurse, pharmacist, and/or therapist, among others. Definingsuch requirements may include selecting a disease and/or condition. As adisease and/or condition may include multiple different attributes,defining the requirements may include selecting one or more diseaseand/or condition attributes. Some embodiments provide that one or morefunctional components of the condition specific application may beselected based on which ones of the disease attributes are selected.

Once the functional components are selected and/or identified, thecondition specific application may be built based on the requirements(block 104). The condition specific application may be built by definingfunction metadata corresponding to the one or more functional componentsof the condition specific application. Some embodiments provide thatfunction elements may be defined based on the function metadata.Additionally, a function interface that corresponds to the functionalcomponents may be defined and/or generated.

The condition specific application may then be configured correspondingto one or more user-specific attributes (block 106). For example, userattributes may include communication related information and personalidentification information. Examples of personal identificationinformation may include names, gender, ethnicity, date of birth, placeof birth, citizenship, subscriber identity module (SIM) card identifier,and/or residence information including street address, city, stateand/or postal/zip code. Some embodiments of communication relatedinformation include a mobile terminal numerical or email address and/orphone number, the country or region (e.g., Canada, which has French andEnglish languages) in which the mobile terminal is located and/or inwhich communication services originate, a language preference and/ormedia access control (MAC) addresses and/or ethernet hardware addresses(EHA) corresponding to wireless short range and/or NFC communications.

In some embodiments, configuring the condition specific applicationcorresponding to user-specific attributes includes defining generalrules and/or workflow corresponding to the condition specificapplication. Additionally, condition stages that are specific to thecondition may be configured. In some embodiments, behavior stages of theuser that correspond to condition stages may be mapped. Knowledgebasecontent may be mapped to the condition stages and/or the behaviorstages.

In some embodiments, capabilities corresponding to the processingdevice, the user and/or a peripheral device may be assessed. Thecondition specific application may be packaged corresponding to thecapabilities of the processing device, the user and/or the peripheraldevice.

Some embodiments provide that user information includes lists ofinstalled and/or accessed applications and versions thereof.Additionally, user information may include identifiers corresponding tothird party applications including, for example, Twitter, Skype,BlackBerry, and/or Facebook among others. User information may furtherinclude communication service terms including contract type (monthly,annual, prepaid, etc.), and a defined service area and/or areasidentified based on signal strength and/or quality.

The condition specific application may be delivered to a processingdevice that is operable to execute the condition specific application(block 108). Additionally, the packaged condition specific applicationmay be modified to include user specific data (block 110). For example,one or more components and/or operating modes of the condition specificapplication may be modified responsive to a change in the conditionand/or user behavior.

The processing device may include a mobile and/or fixed terminal thatincludes and/or is communicatively coupled to at least one processor.Some embodiments provide that a mobile terminal may include a personaldigital assistant (PDA), cell phone, pager and/or a machine that doesnot include a direct human communication interface in order to service aremote area and/or one in which a user may not have a persistent orreliable data connection, The mobile terminal may provide that mDNA datamay be stored in a fixed memory location in the mobile terminal and/ormay be stored in a removable media. Additionally, some embodimentsprovide that removable storage media may be used to transmit data to themobile terminal using a physical delivery system.

Reference is now made to FIG. 2, which is a block diagram thatillustrates operations and workflow corresponding to systems and methodsaccording to some embodiments of the present invention. Specifically,the diagram illustrates a high level view of systems, methods andcomputer programs for designing, building, delivering and maintaining adisease/condition mobile health solution that provides dynamic supportand management specific to disease/condition. As illustrated, thedevelopment, provision and support of mobile health solutions may bedivided into processes and their respective inputs and outputs,including possible roles of a health professional 210, a service/productprovider 220 and a patient 200.

The health professional 210 may determine patient requirements 212 andprescribe a mobile health solution, also referred to as an mHealthproduct 214. In the event that an mHealth product has previously beendeveloped to address the patient requirements identified by the healthprofessional, then an off the shelf product may be provided 216. In theevent that no off the shelf product is capable of meeting the patientrequirements, then a service/product provider 220 may define therequirements for a disease or condition specific mHealth solution usingdisease knowledge information 232 and the patient requirements 212identified by the health professional 210. An initial product design maybe determined 242.

Once the requirements are defined the mHealth product may be assembled224 using workflows and rules 234 corresponding to the product design,the disease or condition, and/or predefined processes. As a result ofassembly, a functional product of the mHealth solution is ready to beconfigured 226 using mapped behavior and disease stages 236 to produce aworking product 246.

Using mobile device information 238, the product is delivered 228 as apackaged product 248. Once delivered and/or implemented, the patient 200is assessed 204 including determining disease and/or patient changes202. In some embodiments, the product may be revised 206 responsive tothe assessment 204.

Embodiments as disclosed herein may support a whole life cycle of amobile health solution from identifying the specifics of a disease orcondition to building, configuring and verifying a mHealth solution, andthen delivering and adaptively changing the solution when in use by apatient. For example, brief reference is made to FIG. 3, which is a flowdiagram illustrating an overview of stages for providing an adaptivemHealth solution according to some embodiments of the present invention.The first stage includes clinical assessment (block 260). For patientsenrolled onto a solution through a physician or clinical assessment, thehealth professionals may be integrated into the process, allowing theability to specify, review and prescribe solutions.

This methodology allows for physicians and healthcare professionals tobe involved in a mobile health solution's life cycle according to someembodiments herein. For example, a request or prescription for a mobilehealth solution can start with a physician looking to prescribe asolution on its own or in support of a patient's medication and/ortreatment regimen. Requirements identified by a physician can thereforefeed directly into the next ‘Define’ stage and then review the solutioncoming out of the ‘Configure’ stage. Any refinement coming out of thereview can be cycled back through the system and/or approved fordelivery to the patient.

Once the solution is in use by the patient, a physician or healthcareprofessional could continue to view patient or product progress and bedirectly involved in any remote solution adaptations. In someembodiments, solutions can maintain a full audit trail, providing alevel of clinical validation to patient use and outcomes.

The next stage is the define requirements stage (block 262). In summary,solutions may be designed by matching industry classified conditions andpublished findings, with functional solutions that may be mapped from adisease knowledge base, which may include an internal and/or externaldata repository. In some embodiments, a solution design may start inthis stage and may be defined with the support of two or more key datasources. For example, a first may be an internal ‘disease findings’ datarepository maintained through a content syndication engine that extractspublications information on disease/condition research findings. Someembodiments provide that the syndication engine could identify publishedstudies on Acute Coronary Syndrome medication adherence, includingnumerical and textual information on the key issues and potentialsolutions and strategies to overcoming the problems.

The second data source may include an internal ‘disease knowledge base’,which may be a comprehensive repository that captures evidence data ondisease/condition solutions. This data repository is used in sync withconfigurations, content (described in the following stages) and findingsrepositories to connect evidence to working solutions and real worlddata. This data repository may include (but not limited to) how welleach solution configuration works, by disease and demographics. Thedisease/condition classifications may be built on relevant industrycodification standards, such as ICD (International Classification ofDiseases).

The process of building a disease/condition solution may begin withselection of a disease/condition, from which the system can provide alist of key areas (herein referred to as disease/condition attributes orattributes) that need to be considered. For example, selecting AcuteCoronary Syndrome might include the following in the list of attributes:

1. The need to address general state of health

2. Dealing with misbeliefs

3. Moody and emotional feelings are common

4. Forgetfulness is a common reason for medication non adherence

From here, different solutions can start to be visualized by selectingdifferent combinations of attributes in a solutions designer, which mayinclude and/or be included in a user interface, such as, for example, agraphical user interface (GUI), among others. Some embodiments providethat the solutions designer is an automated builder used to create anumber of solution mock-ups that can be individually rated. For example,in the above mentioned Acute Coronary Syndrome list, one scenario mightbe that all four attributes are deemed important and are all selected,while another scenario might only select attributes 3 and 4 in the list.The solution designer may provide a limited amount of configuration andsample content so the solution can be better visualized. Some orsubstantially all of the sample content may be automatically generated.

The solutions designer may then match a list of functional componentsthat can address each of the key attributes selected. These functionalcomponents may include an overview explanation of how eachdisease/condition attribute can be addressed through the correspondingfunctional component, which can then be configured accordingly. Forexample, attribute 4, forgetfulness, will correspond to thealert/reminder component within the platform's software componentlibrary.

This section may also link to evidenced information and examples fromthe disease knowledge base and disease findings repository, providingimportant information in considering the merits of different functionalcomponents and configurations. For example, in Acute Coronary Syndrome,evidence might suggest the importance of building lifestyle changeelements into any adherence solution for any real improvement inpatients being able to better manage their condition in the long term.At the end of this process a final solution design may be selected.

Meta data from the define requirements stage may be used in the buildapplication stage (block 264). The build application stage may providefurther development of the software components. For example, eachfunction starts as an empty framework based on decisions made in thedefine stage with the ability to construct the main workings throughparameterized/scripted selections and/or instructions. It is at thisstage that the rudimentary workings of each component may be defined.For example, if a planning and tracking component has been selected andis intended for use in supporting an acute coronary syndrome patientplan to manage a healthy living program, the function will be set up forhealth activity goal setting and tracking.

Most components may be selected from a modular library and then builtout by defining specific metadata and selecting from a pre-defined setof parameters. More advanced capabilities may also be built through anon-technical scripting language. Some embodiments provide that theenhancement to existing and new components can be separately programmedand added to the modular library.

Previously constructed components can be re-used for a new solution.Fully or partly constructed components can then be refined within thebuild and configure stages to create a new solution. The diseaseknowledge base and configurations repository (described in the Configurestage) can be used to adopt proven and tested configurations. At the endof this process all of the main components may be defined andconstructed, and then may be transferred to the configuration stagewhere the specific rules, workflow and content workings are added toturn the solution into a fully useable product.

In some embodiments, the platform's library will hold an extensive andmaturing set of components, a number of which may form a staple part ofmost mobile health solutions. The following is an example of just a fewcomponents.

Care Plan.

A recurring requirement in healthcare management is the need forpatients to have an individual care or health plan. This function mayprovide each patient their own individual plan which could include (butnot be limited to) key clinical data that patients should be aware ofand a list of any personal goals that show progress and achievement.Care plans can form an important role in a patient's healthcaremanagement, and as such can be configured and used in different ways.The care plan may ultimately be where everything comes together for thepatient, in that they can see everything of importance to them in acentralized presentation. The care plan may also act as an importantinterface between the physician and patient.

Goal Management.

Central to a patient managing their healthcare may be the need to setgoals that might be related to medication adherence, activity, lifestylechanges, psycho social barriers and/or any other factor that contributesto helping them better manage and potentially improve their condition.When configured, these functions can be set up in an engaging form, forexample, bringing an element of gamification (i.e. using gamingtechniques to encourage people to perform healthcare related activities)to their activity targets by making them part of an interesting campaignto walk the equivalent of a marathon in a specified time.

Device/Sensor Integration.

Also central to mobile healthcare solutions may be the ability tointegrate with medical and healthcare devices and sensors whereappropriate. Such devices can be integrated into solutions utilizingindustry standards wherever possible.

Further components may include assessment, reminders, education and/orreward, among others. These components could be delivered in a number offorms utilizing rich media, device technology/peripherals and socialmedia where appropriate.

In addition to components described herein, systems and methods may beintegrated into PHR/EHR solutions like Healthvault, as well as providingone or more API's to allow integration into the systems/methods. In someembodiments, third party components and/or configurations can form partof an extended library as well as adding evidenced findings to thedisease knowledge base.

Once the build stage is performed, the application may be configured(block 266). For example, all functions may then be configured bymapping in stages of disease, behavior and medication (amongst others),as well as content, to create a complete working solution.Configurations may be built based on previous findings to provideeffective patient engagement. During the earlier define stage (block262), the previously described solution designer can be used to add abasic level of configuration and some sample content to help visualizethe workings of the solution. In the configure stage (block 266), theconfiguration details and content may be more comprehensive and theselection of specific configurations and content may be supported byevidenced data from the disease knowledge base and/or an internal datarepository for configurations.

In some embodiments, a configuration repository may capture metadata forconfigurations used on existing disease/condition solutions. Furtherstill, results of patients using these configurations (i.e. how well theconfigurations worked) may be stored in the disease knowledge base. Thedisease knowledge base therefore may help configure solutions for abetter patient outcome. With growing patient usage and increasingsolutions, the disease knowledge base may be continually refiningpatient solutions. Some embodiments provide that results of the refinedpatient solutions may be published.

The configuration process may begin with a rules and workflowsrefinement, ensuring that all components function correctly and combineto work effectively. In some embodiments, solutions may be configureddynamically. For example, the solution may adapt to disease, condition,medication, patient, and/or other progressions (herein referred to asdisease stages), so that content and actions adapt to better support thepatient through these changes. For example, if a patient's conditionchanges, the solution will adapt to provide updated and relevant contentand actions. Each of the disease stages may be defined by key datapoints that indicate a change. The data points may be mapped to rulesthat effect content and action changes.

Additionally, behavioral modification stages can also be mapped in asimilar way. In some embodiments, behavioral modification may refer topatient's behavioral changes between different stages. Such changes mayinclude denial and not dealing with their condition, accepting theircondition but not yet dealing with it well, starting to get on top ofmanaging their condition, and/or pro-actively managing their condition,among others. Behavioral modification stages may also be defined by keydata points that indicate a change. The data points and/or the changesthereof may be mapped to rules that effect content and action changes.Behavioral changes might adapt content and/or actions to provide theright motivation and support offering the right level of behavioralre-enforcement.

To complete the configuration, a final pass is carried out that mapscontent into the solution. In some embodiments, content may include allthe instructional and educational information. The content may bestructured in a modular form so that it can be combined and consumed inmultiple forms, for example, tip of the day, coping strategies,reminders, looking up advice, education and so on. The content may bemapped to the different components as well as disease and behavioralstages. Further, content can also be categorized and delivered bypatient demographic, allowing for areas like language and reading age.Educational content can be adapted to individual patient's learningstyle.

Content which is proprietary can be set up within the internal contentrepository for use in specified solutions and for specified timeperiods, as set out in the content's licensed terms of use.

Once the application is configured, it may be delivered (block 268).Some embodiments provide that patient device capabilities/userrequirements may be assessed and an appropriately configured solution isuploaded. For example, systems and methods disclosed in above referencedpending patent application Ser. No. 13/459,573 filed Apr. 30, 2012,entitled “Systems, Methods and Computer Program Products For ProvidingCompliant Delivery of Content, Applications and/or Solutions” (“the mDNAsystem”) may be used in the delivery of the application. For example,the mDNA system may be used to identify a patient's device, user andperipheral chromosomes, from which the most suitable solutionconfiguration can be uploaded.

Any solution may be device agnostic and can be configured for accessthrough one or more devices, including (but not limited to) cellularphone, tablet PC and internet TV, as well as being accessible through abrowser based patient portal. From the outset, reference to a mobilehealth solution has referred to not just cellular device basedsolutions, but to a solution that is made individually accessible foreach patient through the most readily available mediums. For example,physicians and health care professionals may use the portal to assessand/or review patients/solutions. It is also possible to extend anysolution to individual caregivers and caregiver networks, providingpatients extended support.

At this stage the patient can access a sophisticated solution that hasbeen designed and built to support them in the most comprehensive way.The patient can however further refine and personalize the solutionadapting how it is utilized. This might include configuring how theyinteract with the solution or how they prefer to consume content. Theymay also be able to prioritize the how the solution works, focusing onwhat is most important to them. Finally, the patient may have some levelof ‘look and feel’ configuration, allowing them to maybe changewallpaper, font, etc. The level of personalization may be set up duringthe build and configure stages, but may be later modified as well.

Importantly, the building and configuration of a solution prior to beingdelivered to a patient, as well as the level of configuration a patientcan carry out, all work within safe working boundaries for the patient.This may be achieved through a combination of pre-defined parameters anda rules engine that can dynamically monitor and respond to changes.

After the solution has been delivered, the use and adapt stage (block270) may provide a dynamic approach to adjusting content and actions.For example, once in use, the patient can be dynamically monitored,adapting functions and content according to a patient's progression.Some embodiments provide that adaptive elements are mapped into the coresolution, enabling actions and content to be locally adapted. However,the systems and methods herein may also carry out remote assessment andupdates.

Patient engagement or solution effectiveness can be assessed and updatedremotely. Any such assessments and updates may be carried out within thestrict bounds of customer terms and patient consent. Such remoteassessments may work off of a patient consented, anonymized datarepository. This repository may collate anonymized patient data,monitored for specific trends, e.g. content used by patients with themost successful outcomes. Remote updates can then be uploaded torelevant patient devices.

Regional patient consent and data privacy parameters may be fullycaptured and strictly tracked to provide that data is only collected andutilized for consented uses and maintained accordingly. Individualpatient data may be assessed and solutions updated strictly within theseparameters. Where appropriate, the consent/data privacy process can alsoallow patients to waive rights to local data protection law.

In addition to the locally provided solutions, systems and methodsherein may be integrated into the broader healthcare ecosystem,integrating physicians and healthcare professionals, as well ashealthcare systems and data. In some embodiments, integration mayutilize adopted industry standards, which might include (but not limitedto) ICD codifications and EHR/PHR standards/platforms. As well assupporting the development of new mobile healthcare solutions, thesystems and methods herein can also be used to prescribe existing mobilehealthcare solutions.

Systems and methods disclosed herein may support a range of users,including (but not limited to) patients, caregivers, payers, physiciansand healthcare professionals. Each type of user can access relevantfunctions and data through a secure and customizable portal (in additionto any device access).

Reference is now made to FIG. 4, which is a flow diagram illustratingthe stages described above regarding FIG. 3 including operations andflow therein according to some embodiments of the present invention. Theclinical assessment 260 may provide that an mHealth requirement isdetermined by a health professional 302. In the define stage 262, adisease may be selected 320 and information corresponding to diseasefindings 312 may be accessed and/or retrieved. The disease findingsinformation 312 may be source from a data syndication 310, publications308, including paper publications 306 and/or a disease knowledgebase 330or other data repository. Once the disease is selected, diseaseattributes may be selected 322 and the disease specific functionalcomponents may be selected 324.

The build stage 264 may include defining the function metadatacorresponding to the function components 340, the function elements 342and the function interface(s) 344. In configuration 266, rules andworkflow may be refined 350. The disease stages 352 and the behavioralstages 354 may be configured. Based on the configurations and internaland/or external disease specific content 326, 328, the content may bemapped. Additionally, the configurations may be stored 332.

In the delivery stage 268, the mDNA assessment 360 can be used todetermine details regarding delivery of the solution. Based on the mDNAassessment, the product is packaged 362 and may be personalized for thepatient 364. Once in use 270, the solution may adapt to patientinteractions 370, disease progressions 372, behavioral changes 374and/or patient side effects 376. Such changes may be reviewed 304 andthe findings included in the disease knowledgebase 330.

Being an integrated part of a healthcare ecosystem, the systems andmethods herein may support new workflows. For example, a physician canprescribe an existing mobile healthcare solution and then support apatient directly through the product. This may include reviewing apatient's progress through the physician portal, and then uploadingchanges to a patient's mobile device. Further still, care plans can forman integral part of any workflow, with care plans updated by a physicianor healthcare professional after a patient review.

An example integration across healthcare provider, solution provider andsponsor is shown in FIG. 5, which is a block diagram illustratingoperations and workflows corresponding to systems and methods asdisclosed herein integrated within a healthcare ecosystem in accordancewith some embodiments of the present invention. This shows how aphysician might also take into account prescribed drug needs, ensuringthat a mobile health solution utilizes the right functions andconfigures them appropriately for patient use. Components may theneither be built or selected from a library if already available.

Referring to FIG. 5, a healthcare provider may utilize, update and/oradd a medical record to a data repository 402. Key disease attributesmay be provided to a service and/or product provider 404. A disease andsolution database that is provided, serviced and/or maintained by aservice/product provider is searched 412. Additionally, based on the keydisease attributes, prescription drug information is analyzed and/ordetermined 406.

Responsive to one or more patient device interactions 428, mDNA providesdelivery specific information 420. The service/product provider may alsoquery a sponsor 422 to determine sponsor provided disease/druginformation 426. The service/product provider may provide diseasespecific solution components 414 responsive to the disease/druginformation 426, the mDNA delivery specific information 420 and/or thesearch results from the disease and solution database 412.

The healthcare provider may select from available ones of the componentsmatching the disease and/or behavioral profile 408 and prescribecomponents to the patient 410. A determination as to whether customizedcomponents are required is made 416. If customized components arerequired, then the build stage is employed to generate the customizedcomponents. Otherwise, previously generated components are provisioned424 and then personalized and used 430.

By way of example, patient A is a fourteen year old boy with CysticFibrosis (CF), which is a life-threatening inherited disease. It iscaused by a faulty gene that controls the movement of salt and water inand out of the cells within the body. CF affects the internal organs,especially the lungs and digestive system, by clogging them with thicksticky mucus. This may cause breathing and digestion difficulties.Previously about fifty percent of CF patients lived beyond 41 years ofage, but with the support of healthcare solutions today, patient A mayexpect to live longer.

For example, when participating in a CF mHealth program, patient A andhis parents may receive a comprehensive range of support mechanismsdelivered directly to them. The requirement was initially identified bythe family physician, when patient A was starting to rebel against theneed for daily treatments. The requirement for a treatment, lifestyleand condition management solution identified an mHealth product that mayprovide the following disease specific support in the following manner.

First an mHealth product may include prescription and treatmentmanagement. In this manner, patient A may better manage both medicationsand treatments. He can set it up to remind him in the most appropriateway and time that his medications are due as well as monitor and manageprescription refills. Since daily physiotherapy treatments for patient Amay be demanding, the mHealth product may assist the family inorganizing and planning treatments in the most effective way.

Additionally, an mHealth product may provide nutrition and activitymanagement. Good nutrition and an active lifestyle may be importantfactors in contributing to CF patients quality of life and longevity. Assuch, the nutrition management function may help patient A (and hisparents) ensure appropriate nutrition. Additionally, the mHealth productmay allows patient A to manage his caloric intake and ensure the rightlevel of fat intake for his medication. The activity function may makeexercise more engaging for patient A, for example, by allowing him tocarry out activity events of interest within online social groups.

The mHealth product may include assessment functionality. For example,it may be important that CF patients monitor for any early indicationsof chest infection. The mHealth solution can help monitor both directlyby looking for any signs of patient change and indirectly by carryingout short, regular assessments. Early identification of and earlytreatment of infections with antibiotics may prevent bacterialinfections from establishing themselves and causing potentiallyirreversible damage.

Informational support and education may help patient A and his parentsstay on top of his condition by providing them with the rightinformation and education all the way through his life. This may bedelivered in a variety of forms to ensure they get the right informationin the right way at the right time, which might include tips of the day,coping strategies, education in new techniques and so on.

Additionally, a care/health plan can provide an easily accessible viewof the information, goals, progress and achievements in an individualcare plan. This information can be shared with health care professionalsthrough an online personal health record (PHR) and/or a clinicalelectronic health record (EHR) as patient reporting information.

Further, caregiver support functions may allow caregivers to monitorpatient A as well as being able to manage their own care activities andreceiving caregiver specific information and support. The mHealthproduct may also adapt to changes. These might include patient A's owndevelopment into an adult, in which he legally takes responsibility formanaging himself, as well as adapting to CF condition developments overtime. It is also able to monitor for behavioral changes ensuring thatboth patient and caregivers are supported through difficult stages.

Patient A's family physician was able to identify a readily available CFmHealth solution. The physician is able to prescribe the solutiondirectly through the mHealth platform and continue to monitor thepatient's progress through the platform's physician portal. Briefreference is made to FIG. 6, which is an illustration of the differentfunctions and components in a CF specific mHealth product according tothe example described above.

Reference is now made to FIG. 7, which is an illustration of differentfunctions and components in an Attention Deficit-Hyperactivity Disorder(ADHD) specific product according to some embodiments of the presentinvention. By way of example, Patient B may be a seventeen-year-old malewho has been diagnosed with ADHD and may be facing new challenges inself-management once not under the direct supervision of a parent orother caregiver. This example is presented as a product outlinedescribing the range of functions that may be identified in effectivelysupporting ADHD patients. Some embodiments provide that patients wouldutilize their own mobile devices and existing network connections toaccess the systems and products disclosed herein. Additionally, systemsmethods and computer program products herein may further incorporateprograms that rely on the support of third parties, including forexample, parents, relatives, caregivers, teachers and/or healthcareprofessionals, among others.

Patients may enroll in the program via multiple different entrancepoints. Such entrance points may include direct registration by thepatient, registration through a primary caregiver and/or registrationthrough another institution, such as for example, a college or othereducational institution. Some embodiments provide that functionality isdesigned to work around the patient, supporting them in achieving agreater degree of self-management and may be presented as a lifestyletool that incorporates patient anonymity. For example, productfunctionality may be delivered in a manner that preserves the patient'sself-esteem, while offering the patient an opportunity to morecollaboratively engage others.

Some embodiments provide that a healthcare provider may enroll thepatient via a portal corresponding to the systems and methods describedherein (block 450). Enrolling the patient may include registeringdetails corresponding to the patient and/or the patient healthcondition, evidence of and/or information corresponding to patientconsent, and/or one or more different patient setup criteria.

A patient may set up their system and/or a profile corresponding totheir system by loading one or more corresponding software modules ontoa personal device (block 460). Some embodiments may include providing abasic overview of the system and receiving reminder data, goal dataand/or preference data that may be used to configure the system. Oncethe system is set up, a baseline assessment may be established and mayinclude a profile of the patient (block 462). The assessment functioncan cover a number of patient information capture and/or assessmentoperations. In some embodiments, a baseline assessment may be used tosegment patients when first enrolling, allowing the system to thenrespond to different profile needs. For example such an assessment maybe used to determine the patient's self-management readiness. In thesetup stage, the patient may define personal preferences to furtherpersonalize their interaction.

Results of the assessment function may be used in combination with ADHDprofile maps to determine relevant content (block 464). Content mayinclude information and education content that may be mapped to thefunctions within the systems disclosed herein to deliver individualpatients information that is relevant to their condition, that ispresented in a meaningful way, and that is delivered in an order and ata time that may correspond to the relevant condition. In someembodiments content may include content from a pharmaceutical companythat may be utilized in addition to additional externally providedmaterial. In some embodiments, the content may include genericself-management material in addition to relevant ADHD condition specificinformation. For example, providing patients with an awareness regardingsocial skills may be delivered in the form of coaching.

Additionally, specific assessments may also be set up to runperiodically and/or triggered by an event. For example, Patient B mayhave a pedometer that indicates that activity levels have reduced. Thisindication may trigger a simple assessment to determine how Patient B ismanaging. Other assessments may be set up corresponding to one or morespecific purposes, for example, dose titration, which may be assessed tocapture efficacy and/or safety events, among others (block 466).Depending on results from specific assessments, medication regimens maybe monitored and adapted (block 456). In some embodiments, the specificassessments may be used in combination with a healthcare provider whomay view efficacy and/or side effects via portal access, and adjustmedication accordingly.

Treatment management data may be received, for example, via reminderdata and content provided based on dynamic rules (block 452). In someembodiments, patient data may be used to set up medicine managementprotocols including medicine identifications, dosages, refill data,reminders, and/or cautions or warnings. Treatment management data mayinclude an identification of medications, refill information, scheduledand/or proposed appointment visits, and/or medical record informationsuch as vaccination records, among others. In some embodiments, refillnotifications may also be sent to one or more other concerned parties,such as a parent or guardian of Patient B (block 454). Some embodimentsprovide that a treatment management function may include more than justtraditional medication reminders. For example, patient non-adherence mayoften occur at the end of the series of issues that have cumulativelyresulted in the patient deciding not to proceed further with medication.Such issues may include titration difficulties, concern over sideeffects, forgetfulness, misinformation and/or a lack of understanding.In this regard, a treatment management function may combine toolsinformation and healthcare provider engagement to assist Patient B inmanaging their medication.

In some embodiments, one or more sensors and/or devices may beintegrated into systems and/or methods disclosed herein. For example, inthe context of Patient B having ADHD, an activity monitor such as aBluetooth pedometer may be used to monitor a change in activity (block470). Some embodiments provide that the activity may also be monitoredusing one or more accelerometers devices that may be included in asmartphone. The activity measure may be used as a monitor of thepatient's state and may provide activity data for profiling thepatient's movement profile from which the patient's different states maybe mapped. For example, a wellness assessment may be performed based onthe activity measure (block 468). In this manner, the patient's changein state may be detected in the systems and/or methods disclosed hereinmay provide a proactive response corresponding to changing needs.

The measure of activity may be used as a part of a patient's activitygoals. For example a goal management function may allow patients to setand work towards personal goals (block 472). The build may be unique andmay be provided by the patient and/or may be selected from predefinedgoals corresponding to, for example, ADHD. In some embodiments the goalsmay include goal programs for example dietary programs that contain mealinformation to help the patient work towards a better balanced diet.Additionally, goal programs may be linked to collaborative activitiessuch as engaging patient and support networks (block 474). Additionally,systems, methods and computer program products herein may incorporategoal management tools that rely on support from external organizationsand/or institutions, such as for example, a college or other educationalinstitution (block 476).

Informational and educational content 480 may be combined with collegecontent 482 and access by the patient using multiple different devicesincluding smart phones, tablets, laptops, desktops, and/or other networkand/or Internet capable devices (block 458).

Some embodiments provide that systems, methods and computer programproducts disclosed herein may incorporate and/or be supported bymultiple different social media tools that may engage patients incollaborative groups. For example a simple support our mentorship levelmay connect the patient with a parent and/or teacher that may offermechanisms for collaborative exchanges, monitor achievement, etc. Thesetools may be managed through one or more controlled social interactionproducts and/or may utilize more open social media products. In thismanner, an ADHD patient may be provided with the ability to initiateparticipation in collaborative ventures, conversations and/or groups,among others.

In some embodiments, systems, methods and computer program productsdisclosed herein may be delivered in a manner that engages patients andmay work towards applying a developing skill sets relevant to ADHD. Forexample, gaming techniques may be used to engage users and patients inachieving particular outcomes. In this manner, content may be deliveredin a fun, relevant and engaging way.

By virtue of the systems, methods and computer program productsdisclosed herein, the patient who may otherwise be unwilling to haveparents or relative caregivers directly monitoring and are supportingtheir self-management, may receive support from the parent or relativecaregiver as collaborative support rather than parental monitoring. Forexample, the patient and parent may identify collaborative goals andactivities to work on together. As part of this, the patient may then bewilling to have a parent monitor drug adherence by providing a reminderand/or in support of aspects such as prescription refills. The parent orrelative caregiver function may also be an effective support mechanismby providing help and strategies in supporting adult children.

Additionally, systems, methods and computer program products disclosedherein may extend to integrating and supporting educational institutionprograms. For example Internet portal access may allow schools andcolleges to set up and incorporate their own ADHD programs, which mightinclude a college's own support content, including, for example,effective strategies for the classroom. Some embodiments provide theteachers with an ability to work with ADHD students to agree and worktoward specific goals using the systems and methods disclosed herein.Depending on the approach to implementation, schools and/or colleges maybe directly involved in enrolling patients into the program, althoughteaching staff will have access to their students non-clinical patientinformation.

Additionally, systems, methods and computer program products disclosedherein may include a physician and/or other healthcare professional asan integral part of an ADHD solution. For example the physician orhealthcare provider may enroll the patient into the program via a portalthat includes patient consent, registration and set up within thesystem. In some embodiments, pharmaceutical companies may provideadditional support in getting patients enrolled in such a program. Anenrollment portal may provide a range of functions to help healthcareproviders better support their patients. Such functions may include, forexample, titration management, working with a patient self-managementplan, and/or proactively monitoring patient progress, among others.

The data collected according to the systems, methods and computerprogram products described herein may provide significant real-time dataresources that may be used by the system to profile individual and/orpopulation level interactions, from which the system can adapt toprovide more targeted and effective interventions. A body of anonymizedpopulation data may be gathered via the systems and methods herein andmay provide additional significant insights regarding ADHD patientpopulations.

Reference is now made to FIG. 8, which is an illustration of differentfunctions and components in a Chronic Obstructive Pulmonary Disease(COPD) specific product according to some embodiments of the presentinvention. By way of example, Patient C has been diagnosed with COPD.This example is presented as a product outline describing the range offunctions that may be identified in effectively supporting COPDpatients. Some embodiments provide that patients would utilize their ownmobile devices and existing network connections to access the systemsand products disclosed herein. Additionally, systems, methods andcomputer program products herein may further incorporate programs thatrely on the support of third parties, including for example, parents,relatives, caregivers, teachers and/or healthcare professionals, amongothers.

Patients may enroll in the program via multiple different entrancepoints. Such entrance points may include direct registration by thepatient, registration through a primary caregiver and/or registrationthrough another institution. Some embodiments provide that a healthcareprovider may enroll the patient via a portal corresponding to thesystems, methods and computer program products described herein (block650). Enrolling the patient may include registering detailscorresponding to the patient and/or the patient health condition,evidence of and/or information corresponding to patient consent,retrieving, receiving, capturing and/or entering medical and/or personaldata. For example, data may be pulled from patient records and/orcaptured from other sources.

Patient access may be initiated and patient specific data may beconfigured and/or used to configure solutions as provided herein (block651). A patient may set up their system and/or a profile correspondingto their system by loading one or more corresponding software modulesonto a personal device (block 660). Some embodiments may includeproviding a basic overview of the system and receiving and/or providingreminder data, goal data and/or preference data that may be used toconfigure the system. In the setup stage, the patient may definepersonal preferences to further personalize their interaction.Additionally, further patient consent features may be incorporated.

In some embodiments, patient data may be used to set up medicinemanagement protocols including medicine identifications, dosages, refilldata, reminders, and/or cautions or warnings (block 654). Treatmentmanagement data may be received, for example, via reminder data andcontent provided based on dynamic rules (block 652). In someembodiments, patient data may be used to set up medicine managementprotocols including medicine identifications, dosages, refill data,reminders, and/or cautions or warnings. Treatment management data mayinclude an identification of medications, refill information, scheduledand/or proposed appointment visits, and/or medical record informationsuch as vaccination records, among others. Some embodiments provide thata treatment management function may include patient reminders (block657).

A patient assessment may be established and may include clinicalassessment (block 662). The assessment function corresponding to COPDmay cover a number of patient information capture and/or assessmentoperations. In some embodiments, a patient assessment may assessdifferent physiological functions and/or conditions such as a degree ofbreathlessness, the presence or characteristic of sputum, type andfrequency of cough, and/or ankle swelling among others. Patient reporteddata may be received and may include oxygen saturation, body temperatureand/or peak expiratory flow, among others (block 664). Additionally, aninhaler monitor may provide data corresponding to compliance and/orrescue use (block 666).

In some embodiments, one or more sensors and/or devices may beintegrated into systems and/or methods disclosed herein. For example, inthe context of Patient C having COPD, an activity monitor such as aBluetooth pedometer may be used to monitor a change in activity (block670), Some embodiments provide that the activity may also be monitoredusing one or more accelerometer devices that may be included in asmartphone. The activity measure may be used as a monitor of thepatient's state and may provide activity data for profiling thepatient's movement profile from which the patient's different states maybe mapped. For example, in the case that Patient C experiences anactivity drop (block 674), systems and methods herein provide that anassessment may be initiated (block 676), an activity goal may be updated(block 678), and/or an advice action may be generated (block 679), amongothers.

The assessment and/or data collected therefor may be used to detect acondition change and/or provide an advised action for the patient (block668). In this manner, the patient's change in state may be detected inthe systems and/or methods disclosed herein may provide a proactiveresponse corresponding to changing needs.

Data corresponding to the enrollment operations may also be used todefine the type of core content that a patient receives based on thestage of the patient's COPD (block 656). The defined content 680 may beaccessed by the patient using multiple different devices including smartphones, tablets, laptops, desktops, and/or other network and/or Internetcapable devices (block 658). The content 680 may include information andeducation content that may be mapped to the functions within the systemsdisclosed herein to deliver individual patients information that isrelevant to their condition, that is presented in a meaningful way, andthat is delivered in an order and at a time that may correspond to therelevant condition. In some embodiments, content may include contentfrom a pharmaceutical company that may be utilized in addition toadditional externally provided material. In some embodiments, thecontent may include generic self-management material in addition torelevant COPD condition specific information.

Additionally, systems and methods disclosed herein may include goalmanagement functions that may allow patients to set and work towardspersonal goals (block 672). The goals may be unique and may be providedby the patient and/or may be selected from predefined goalscorresponding to, for example, COPD. In some embodiments, the goals mayinclude goal programs, such as, for example, activity and/or dietaryprograms that contain meal information to help the patient work towardsa better balanced diet.

The data collected according to the systems and methods described hereinmay provide significant real-time data resources that may be used by thesystem to profile individual and/or population level interactions, fromwhich the system can adapt to provide more targeted and effectiveinterventions. A body of anonymized population data may be gathered viathe systems and methods herein and may provide additional significantinsights regarding COPD patient populations.

Some embodiments of the present invention provide that the patientportion of the system may focuses on supporting the patient to betterself-manage their condition. In this regard, the system can be set up tomonitor and support the patient with the aim of identifying earlyindications of exacerbation and preventing hospital or clinic visits.

Assessment and/or monitoring may be provided using methods and systemsdescribed herein. The level and type of patient direct assessment may betargeted at a maintainable level for the patient and may be designed tomake information capture as easy as possible. Some embodiments providethat these direct assessments can be supported with backgroundmonitoring, in which key parameters are identified and monitored forchange. In some embodiments, patients may be prompted at pre-definedintervals and/or based on patient outcomes, e.g., increased use ofrescue treatment, reduced activity. A range of different assessmentsdesigned for pre-determined patient triggers and/or as periodic checksmay be generated. As discussed above, information requested mightinclude sputum rating, cough properties, ankle swelling, breathlessness,and/or a symptom score, among others.

Some assessments might capture medical device readings, which thepatient may read from the device and capture manually, e.g. oxygensaturation, body temperature, lung function. Data may also be captureddirectly from wireless medical devices. As with general assessments,medical device readings may be prompted at pre-defined intervals and/orbased on patient outcomes. Wireless devices might include inhalers orpedometers. The system may receive external environmental data onregional pollen count and air pollution to provide patients alerts andadvice when levels are at a level that could impact the patient.

Some embodiments provide that patients can be assessed directly(explicit assessments) to identify any change in behavioral state and/orindirectly (background monitoring) based on pre-identified parameters.This data may be used to support patients and may include encouragement,promotional programs and reduced risk. Specific behavioral interventionmodels may be adopted, including, for example:

-   -   Health belief model, in which patients alter health related        behavior according to perceived severity    -   Relapse prevention model, which promotes prolonged healthy        behavior by making distinctions between lapses and re-lapses    -   I-Change model, built around awareness, motivation and action        As part of background monitoring, the system may capture patient        usability data, which can be used as key parameters in helping        identify behavioral changes.

A treatment management function may support a patient in managing allaspects of their clinical treatment, including medication, vaccinationsand clinic visits. A patient may have the ability to set preferences inhow the system reminds them to take medications and confirm they havedone so. Multiple different types of medication can be included, e.g.pills, inhaler medications, liquids, suspensions, epidermally appliedmedicines and/or oxygen therapy, among others. In some embodiments, thepatient may receive informational and education support via the systemto help understand important information related to their medication(s).

In some embodiments, systems and methods described herein may allow apatient to define the quantity of available pills and/or activations andcountdown against usage, advising ahead of time when refills are due.Refills may then be confirmed and counters appropriately reset.

In some embodiments, systems and methods herein may prompt a seasonalflu vaccination reminder if appropriate. An individual patient's fluvaccination status may be maintained, which may be updated by thepatient. Such functionality may further be supported by flu information,e.g. when advising to book a flu vaccination, the patient may beprovided with information on why this appointment is so important toCOPD patients.

Some embodiments provide that a clinic visit management feature mayprovide functionality through which a patient may set personalappointment reminders. These appointments may be identified byappointment type and may be supported by corresponding informationrelated to the type of appointment. For a pulmonary rehabilitationappointment, in addition to reminders, the patient may receivesupporting information relevant to their stage of the program, e.g.“well done Tom, you have nearly completed your PR program, your finalvisit is next Monday at 10 am.”

Some embodiments provide a goal management function that providespatients the ability to set goals/objectives. As such, patients may beenabled to define their own personal goals, provide a predefined list ofgoals (e.g. dietary goals could include, 5 fruits and vegetables a day,sufficient daily fluids), and/or provide programs that support specificgoals (e.g. a specific exercise program that a patient can follow,perhaps in support of their pulmonary rehabilitation). For example, apatient may set themselves the goal to increase their daily step count,which would be based on guidelines the patient is provided aboutactivity. The patient may set themselves the target of walking to aspecific destination daily, which may ensure they cover a minimumquantity of steps per day. If the patient carries a wireless pedometer,the pedometer may monitor the patient's activity and may provideencouragement and/or recognition of their achievements. Some embodimentsprovide that goal management may include common goals, like quittingsmoking, but may refer the patient externally to supporting content orprograms.

In some embodiments, content in the system may be provided by multipledifferent inputs including the data collected. Additionally, the systemmay provide multiple different outputs, which may be the informationpresented to and/or provided to the patient. The latter, which isreferred to here as content, represents all the information andeducation content which a patient may receive and/or access according tosystems and methods herein. Content to be used in the system may besourced from a combination of sources. For example a systems mappingexercise may provide that available and required content would be mappedagainst profiles, rules and/or events to ensure that patients receive acombination of routine content and outcome based content.

Reference is now made to FIG. 9, which is a block diagram illustratingsystems/methods/operations for providing condition specific adaptivecontent according to some embodiments of the present invention. Aknowledgebase 504 may include one or more data repositories thatincludes content that is acquired, stored and/or maintainedcorresponding to one or more conditions. For example, in the healthcarecontext, the content may include a knowledgebase containing metadatacorresponding to healthcare conditions including disease and/orcondition information. The knowledgebase 504 may be configured toreceive source data 502 from one or more external data sources 502and/or types of data sources. An individual dataspace 508 may includedata corresponding to an individual instance. For example, in thehealthcare context, an individual data space 508 may correspond to aspecific patient. In this regard, the individual dataspace 508 may alsobe viewed as a personalized dataspace. In some embodiments, data in theindividual dataspace 508 may be encrypted before transmission, duringtransmission, upon receipt and/or before storage therein. Someembodiments provide that the individual dataspace 508 may receive datathat has been de-identified from a corresponding individual prior toreceipt and storage. In this regard, while the individual dataspace maybe personalized regarding the data, such personalization may be storedwithout any identification of the corresponding person.

In some embodiments, data corresponding to the individual dataspace 508may be used by a context module 510 to generate a context correspondingto the individual. The context may be used by the knowledgebase 504 togenerate a solution, process and/or plan to be applied in the individualdataspace 508. Additionally, changes corresponding to the individualdataspace 508, such as metrics corresponding to the solution, processand/or plan may be provided to the context module 510 to identify anychanges in the context, which may be reprocessed within theknowledgebase 504 to modify the solution, process and/or plan responsivethereto.

While the individual dataspace 508 may include data corresponding to anindividual entity, an aggregate dataspace 506 may also receive contentfrom the knowledgebase 504. In such cases, the content may be completelyanonymized and delivered as aggregate data. In some embodiments, theaggregate data may be processed and/or analyzed in the aggregatedataspace 506 and results therefrom may be provided back to theknowledgebase 504 to enhance, supplement, replace and/or improve thedata therein.

In some embodiments, an audit trail may be generated corresponding tothe personal dataspace 508, the aggregate dataspace 506 and/or thesource data 502. For example, an audit trail may be used to determinedeletions, additions and/or modifications of data, including time anddate information and identification of the responsible entity.

Some embodiments provide that the data content and/or the data format inthe personal dataspace 508, the aggregate dataspace 506 and/or thesource data 502 may be encrypted to guard against misuse of the data.

Reference is now made to FIG. 10, which is a block diagram illustratingsystems/methods/operations for providing condition specific adaptivecontent according to some embodiments of the present invention. Content520 may be acquired, stored and/or maintained corresponding to one ormore conditions. As used herein, content 520 may include text data suchas articles, numerical and/or alphabetic data, graphical data includingimages and/or video content, and audio content that may be deliveredand/or stored using any of a variety of formats and/or protocols. Forexample, in the healthcare context, the content 520 may include aknowledgebase containing metadata corresponding to healthcare conditionsincluding disease information 532 and drug information 534. Diseaseinformation 532 may include multiple different parameters that furtherdifferentiate properties of the respective diseases and/or conditions.Drug information 534 may include information about specific drugsincluding their capabilities, usage in treatment of specific diseasesand/or conditions, contra-indicators regarding diseases, conditionsand/or treatments, and historical data including performance indicators,among others. The disease information 532 and/or the drug information534 may be received from one or more external sources of data including,for example, electronic and paper publications, syndicated data sourcesand/or disease findings among others.

Some embodiments provide that health plan data 536 that corresponds toand/or is associated with one or more diseases and/or conditions and maybe included in the content 520. For example, health plan data 536 mayidentify and/or define dietary plans and/or exercise regimens thatcorrespond to one or more diseases and/or conditions. Additionally,social media information 538 regarding health plan, disease, drug and/orcondition data that may also be included in the content 520. Socialmedia information 538 may include a variety of social media types thatinclude content specific pages, sites, blogs and/or online communities,among others. As illustrated, the disease information 532, druginformation 534, health plan data 536 and/or social media information538, may be collectively referred to as the source data 502, asdiscussed above regarding FIG. 9.

An individual assessment 540 may provide data and or information that isspecific to the corresponding individual. In the context of healthcare,the individual dataspace 508 may include data generated in an assessment540 of the patient to determine specific data corresponding to thatpatient. For example, identified diseases, conditions, and/or medicaldata may be determined in the assessment 540. In some embodiments,patient genomic information may be included in the assessment. In thisregard, the content 520 may include pharmacogenomics data that mayfurther personalize a patient health plan 548. In some embodiments, thegenomic information may be used to identify and adapt a preventativesolution corresponding to factors in the genomic information.

Another form of individual data may include patient reported outcomes542, such as responses to treatments and/or changes in conditions and/ordiseases, among others. Patient reported outcomes 542 may includeresponses to surveys and/or questionnaires that a patient may answersingularly and/or periodically over a period of time.

The information from the assessment 540 and the patient reportedoutcomes 542 may be used to form a context 544 of the individual. Thecontext 544 may be generated in the context module 510 as discussedabove regarding FIG. 9. The context 544 may be used in combination withthe content 520 by a rules engine 546, which may deliver a patienthealth plan 548 that is specific to that patient with that diseaseand/or condition. The patient health plan 548, which may be in theindividual dataspace 508, may help the patient manage their own healthin a disease and/or condition specific manner. For example, exerciseregimen, drug adherence information, drug reminders, alerts, diagnosticreminders, text messages, etc. For example, the patient health plan maybe delivered to the patient and may include incoming and outgoingmessages corresponding to and in addition to the other content 520.

Additionally, goal management 552 may include support for settingcertain goals corresponding to the patient health plan 548. A patientmay use the goal management 552 to track their individual performanceagainst goals that correspond to the patient health plan 548. Goalmanagement 552 may be used in conjunction with incentivization 554 toassist the patient in managing and reaching goals corresponding to thepatient health plan 548. Incentivization 554 may include and/or beimplemented with one or more reward plans and/or systems 556.Incentivization 554 and reward 556 may be included in the context module510 and may optionally provide data to further refine the context 544.

Additionally, regulatory compliance requirements may vary amongdifferent individuals, based on conditions, data, and/or jurisdictions,among others. As such, the context 544 may also be determined using datacorresponding to regulatory regimes, such as, for example, HIPPA 558.

The content 520 may also be provided via a contract delivery 522 module.In such cases, the content may be completely anonymized and delivered inan aggregate dataspace 506. In the aggregate dataspace 506, analytics524 may be used to provide alerts 530, trend analysis 528 and/or togenerate and/or monitor relative to one or more performance indicators526. Further, some embodiments provide that results of the analytics 524may be provided back to the content 520 to further enhance the datatherein.

Brief reference is now made to FIG. 11, which is a block diagramillustrating different access portal layout screen configurationscorresponding to different classes of electronic devices through which apatient may access systems provided according to some embodimentsdisclosed herein. Systems and methods herein, which may also be referredto as solutions, may provide different portals that correspond to thedifferent conditions and/or diseases. For example, a COPD program onlineportal may be used to enroll a COPD patient by a health careprofessional or provider. Some embodiments provide that the health careprofessional may receive and provide any requisite consent operationsbefore capturing initial patients detail and/or determining any baselineassessment. A system portal may provide a primary access point for anumber of different users and/or types of users. Some embodimentsprovide that users may access the portal through a standard internet webbrowser, however this is by way of non-limiting example. Patients canaccess much of the functionality and content on mobile devices throughthe portal. The system may utilize available screen size as effectivelyand appropriately as possible. For example, as illustrated, a PC display710 may provide significant amounts, types and granularity ofinformation and/or access via different user interface regions 1-5 thatmay be usefully displayed thereon. A tablet display 720 may provide lessavailable screen area and thus the portal may adjust the interface todisplay only interface regions 1-3. Similarly, a smartphone display 730may be significantly more limited in available screen area and thus theportal may only display interface regions 1 and 2.

In this manner, although a patient would benefit from using much of thekey functionality through their mobile device, they are able to bothcapture and consume information through logging into a system portal. Inthe same way that key day to day patient interactions (interface regions1 and 2) are designed for optimal use through their mobile device,patients might prefer to consume some of the richer media content(interface regions 3-5) through the larger browser based portal.

Some embodiments provide that a complete set of anonymized populationdata may be available to provide a detailed view of patient parameters,activity, interaction and/or outcomes. Essentially, all de-identifiablepopulation data may be available to analyze. This anonymized data may belocated and/or stored separately and transactionally updated.

Brief reference is now made to FIG. 12, which is a flow diagramillustrating a high level architecture corresponding to systems,methods, solutions and computer program products according to someembodiments of the present invention. Specifically, FIG. 12 may berepresentative of the distinction between the aggregate dataspace 506and the individual dataspace 508 as discussed above regarding FIG. 9.For example, illustrated is the separation of the personallyidentifiable information (PII) (inside a secure health service network)and other systems and/or databases.

In some embodiments, the solution may be configured in a way to ensurethe logical separation of personal identifiable information from othermodules within the platform. Personal identifiers also known as PIDs area subset of PII data elements that may identify a unique individual andmay permit another person to “assume” that individual's identity withouttheir knowledge or consent.

Some embodiments provide that security elements applied in the platforminclude two factor authentication, emails, in-App notification, MMS,Instant Message and/or SMS messages, among others. In some embodiments,the patient may be enrolled onto the program/study by a health careprofessional. The health care professional may either retrieve thepatient's details from an external system and re-enter those details viaa system portal or an interface to a primary/secondary care system mayprovide these details directly into a system database. The healthcareprofessional may be required to enter either an email or phone number(mobile or landline). Depending on these choices, a choice of two factorauthentications can be provided depending on the patient's individualpreference and/or needs. Some embodiments provide that a generalizedoption may be provided for a patient population.

Some embodiments provide that the patient, although enrolled, isinactive and may remain so until they receive a URL and a passkey. TheURL and passkey may be sent in separate notification media such asemails, in-App notification, MMS, Instant Message and/or SMS messages,among others. To activate their account via the patient portal thepatient may access the link and enter the passkey.

Some embodiments provide that voice may be used in the two factorauthentication. For example, the patient, although enrolled, is inactiveand may remain so until they access a particular URL, which may provideaccess to the patient portal where they may enter a valid usernameand/or passkey. In some embodiments, the URL and/or username may beprinted by the healthcare professional and given to the patient. In thismanner, upon access to the URL, the patient may be requested to enter ausername. An automated voice call may be activated and may call thepatient's landline number at which point they will be presented with apasskey to enter into the patient portal.

Some embodiments provide that the PII and/or the PID are logicallyseparate from the other systems and may also be encrypted. In someembodiments, a foreign key which links the PII/PID to all the othersystems may be provided by a technology that associates a device and auser that does so by storing this information separate from any othersystem, again provided a logical separation between PII/PID and thesystems that may use their mobile and/or email contact information.During the activation process by the patient mDNA will determine whatmobile device (or if it's a landline) they're using and will thengenerate what is known as an mDNA tag.

Some embodiments provide that any “touch-point” to patient data may berecorded which may provide audit trail data corresponding to any access,creation or change to patient data. This audit trail may contain datacorresponding to the user that accessed, created and/or changed thedata, a time stamp corresponding to this action and/or the action taken.The original data value may not be obscured by any change to the datavalue, thus allowing any and all changes to data to be traced back tothe original data value. In some embodiments, the addition of a reason,rationale and/or justification for changing the data value may also bestored. Referencing FIG. 12, the main patient data may be presented viathe health care professional portal, which will be within a secureprivate network that may only be accessed by health care professionaland/or system service providers.

Various embodiments of the present invention are described below withreference to block diagrams illustrating methods, apparatus and computerprogram products according to various embodiments of the invention. Itwill be understood that each block of the block diagrams and/oroperational illustrations, and combinations of blocks in the blockdiagrams and/or operational illustrations, can be implemented by analogand/or digital hardware, and/or computer program instructions. Thesecomputer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, ASIC, and/or otherprogrammable data processing apparatus, such that the instructions,which execute via the processor of the computer and/or otherprogrammable data processing apparatus, create means for implementingthe functions/acts specified in the block diagrams and/or operationalillustrations. Accordingly, it will be appreciated that the blockdiagrams and operational illustrations support apparatus, methods andcomputer program products.

In the drawings and specification, there have been disclosed typicalembodiments of the invention and, although specific terms are employed,they are used in a generic and descriptive sense only and not forpurposes of limitation, the scope of the invention being set forth inthe following claims. Moreover, those skilled in the art will readilyappreciate that many modifications are possible to the exemplaryembodiments that are described in detail in the present specificationthat do not materially depart from the novel teachings and advantages ofthis invention. Accordingly, all such modifications are intended to beincluded within the scope of this invention as defined in the claims andequivalents thereof. The following claims are provided to ensure thatthe present application meets all statutory requirements as a priorityapplication in all jurisdictions and shall not be construed as settingforth the scope of the present invention.

That which is claimed is:
 1. A computer program product comprising: anon-transitory computer readable storage medium having computer readableprogram code embodied therein, the computer readable program codecomprising: computer readable program code that is configured to definerequirements corresponding to disease specific information; computerreadable program code that is configured to generate a disease specificapplication for execution on a mobile terminal, the disease specificapplication including functional elements corresponding to the diseaseand that is configured according to a stage of the disease and acorresponding patient behavioral stage; and computer readable programcode that is configured to deliver the disease specific application tothe mobile terminal based on properties corresponding to the mobileterminal.
 2. A computer system, comprising: at least one processor; andat least one memory coupled to the at least one processor, the memorycomprising computer readable program code embodied therein that, whenexecuted by the processor, causes the processor to: receive conditionspecific information into a data repository; define condition specificapplication requirements corresponding to the condition specificinformation; build a condition specific application based on therequirements; configure the condition specific application correspondingto user-specific attributes; and deliver the condition specificapplication to a processing device that is operable to execute thecondition specific application.
 3. The computer system of claim 2,wherein the condition specific information comprises health conditionrelated data.
 4. The computer system of claim 2, wherein the conditionspecific information comprises receiving disease specific data.
 5. Thecomputer system of claim 2, wherein the processor is further caused to:select a disease; select at least one disease attribute of a pluralityof disease attributes; and select at least one disease functionalcomponent of the condition specific application corresponding to theselected at least one disease attribute.
 6. The computer system of claim2, wherein the processor is further caused to: define function metadatacorresponding to at least one functional component of the conditionspecific application; define at least one function element based on thefunction metadata; and define a function interface that corresponds tothe at least one functional component of the condition specificapplication.
 7. The computer system of claim 2, wherein the processor isfurther caused to: define general rules and/or workflow corresponding tothe condition specific application; configure a plurality of conditionstages that are specific to the condition; map a plurality of behaviorstages of the user that correspond to ones of the plurality of conditionstages; and map knowledgebase content to the plurality of conditionstages and/or the plurality of behavior stages.
 8. The computer systemof claim 2, wherein processor is further caused to: assess a pluralityof capabilities corresponding to the processing device, the user and/orat least one peripheral device attached thereto; package the conditionspecific application corresponding to the plurality of capabilities ofthe processing device, the user and/or at least one peripheral device;and modify the packaged condition specific application to include userspecific data.